코틀린 스터디 컬렉션과 함수형 녹취록

코틀린 컬렉션은 왜 자바의 컬렉션이 있는데도 불구하고 새로 짰을까 ?

• mutable이 mutable 아닌것에 의존하고 있다는게 불안정함 형변환이 되기 때문에 우리는 lsp 계층에 의해서 뮤터블 셋이 그냥 셋으로 부모로 대체할 수 있다. 객체지향의 대체가능성은 자식은 부모로 대체할 수 있다. 여기서 보면 mutableList는 List를 대체하게 되니까 언제나 list처럼 쓸 수 있다는 이야기다. 그래서 항상 이 코틀린의 현재 계층구조에서는 굉장히 불안정하다. list 는 mutable로 mutable은 list로 언제나 타입 캐스팅이 가능함. 걔다가 얘낸 다 인터페이스다 스테레오 타입으로 되어있는 그래서 얘는 구현체 조차도 아님 실제 구현체는 따로 있다는 이야기다. 실제 구현체가 mutable interface를 상속 받았다는 이야기는 list interface를 상속 받았다는 이야기이도 하다. list나 mutableList는 둘다 서로를 타입캐스팅할 수 있음. mutable list를 list로 타입 캐스팅 가능. 여기선 list를 구현한 구상 객체가 보이지 않음. list만 구현한 구상객체조차도 mutablelist로 타입 캐스팅이 된다. 구현체가 list를 구현했을때 mutable list는 구현하지 않도록 해야하는데 실제 현재 코틀린 구현체는 mutable list가 list까지 구현하는 구현체를 가진다. 254 페이지는 클래스 다이어그램이 아니다. 좋은 계층 구조는 인터페이스만으로 되있지 않다. 타입을 확립시킬때는 구상클래스가 개입하게 되있다.OL을 방지하기 위해서 OL이란
• 여기 더 좋은 그림은 리스트를 list를 mutable 리스트로 화살표가 가는데 이렇게가 아니라 abstract list라는 클래스가 list 인터페이스를 가르키고있는 별도의 박스가 있는 것임. 그럼 mutable list로 내려갈 수 없음. mutablelist 밑에도 absctact mutable list라는 클래스가 따로있는게 나을 수도 있다. 이런 경우엔

근데 왜 이런 위험을 감수하고 왜 따로 코틀린 콜렉션을 만들었을까 ?

1. 가장 중요한 이유는 mutable, imutable 구분 할 수 있는 인터페이스를 추가하기 위해서

   • 자바 컬렉션의 가장큰 문제를 mutable, immutable로 보는 것이다.

2. 코틀린 컬렉션은 컴파일러의 다양한 기능에 대해서 지원을 받는다

   • 최상단에interface iterable이란게 있는데 이것의 정체 때문이다. iterable에는 next와 hasNext가 있을것 같지만 그러면 map ,set, list 가 모두 for a in iterable에서 사용할 수 있을것 같지만 하지만 코틀린에서는 iterable을 operator 로 hasNext(), next() 구현했음. 아무 객체나 인터페이스를 사용하지 않고 오퍼레이터로 위의 두개만 구현하면 무조건 iterable이 된다.
   • operator는 객체의 상속 구조를 갖지 않아도 컴파일러가 해석할 수 있음. 컴파일러는 for안에서 아무 객체나 돌아갈 수 있도록 만들어줌 operator로 hasNext와 next만 구현하면 특정 객체 상속 받지 않아도 된다.
   • 이런 혜택이 컬렉션에 적용되어져 있다.
   • 그럼 왜 iterable을 상속을 받고 있을까? 실제로 foreach가 어떻게 구현 되있을까 native foreach가 list나 set에 구현되어져 있는데 우리는 여기에 람다를 넘겨 처리하는데 람다를 foreach란 함수는 안에 무엇으로 구현되어져 있을까? hasNext와 next로 구현되어져 있음. for in으로 구현해도 똑같아짐. 컴파일러의 지원을 받음. 우리는 혜택을 보는 마지막의 클라이언트 함수만 쓰고 있을 뿐이다. 그럼 컴파일러가 인라인 화도 할 수 있다. 컴파일러 상의 인라인 최적화 같은 경우에 다 버프를 받는다. hasNext와 next가 있다는 걸로 for in 을 컴파일러가 hasNext와 next로 바꿀거라 생각하면 안된다.
3. 이게 추상화된 코틀린 프레임워크이기 때문에 특정 언어의 컬렉션 프레임워크가 아니라도 아무 언어로나 인식하기 편하다.

그래서 우리는 언제 IntArray를 써야한다? 박싱을 너무 많이 할것 같을때 사용한다. foreach 했다 map 했다가 난리 칠거면 매번 박싱하는 것 보다 처음부터 박스 객체를 갖는것이 유리하다. Array<Int>는 박싱이 필요 없을때 사용한다. 마지막엔 stringBuilder 의 최후가 toString인 것 처럼 얘한태 toTypedArray으로 마무리한다. IntArray가지고 실컷 괴롭힌 다음 마지막에 toTypedArray를 하면 된다.

4. 컬렉션을 바꿔도 코드 전체를 바꾸지 않아도 된다.

자바는 왜 그렇게 못했을까 ?

1. 이유는 레거시 때문 순차적으로 추가 했기 때문이다. 그당시에 필요한 메서드를 그당시의 객체가 갖고 있었고 컬렉션프레임 워크의 상단을 정의할땐 그것밖에 필요없다고 생각 했던것임 다음 자료구조가 등장할때마다 레거시랑 호환해야 되기때문에 추가할 수 없으니까 구상 클래스마다 각 다른 클래스를 갖게 되는것임. 하지만 자바 플랫폼에서는 캐스팅이됨. 코틀린 컬렉션을 자바 컬렉션으로 캐스팅이 가능. 대표적으로 맵을 linkedHashMap으로 list는 ArrayList로 set은 linkedHashSet으로 캐스팅된다.
2. 우리가 코틀린의 컬렉션 메소드를 사용하더라도 컴파일 될땐 근접하면 자바 메소드를 호출하는 거으로 모두 바뀜. 코틀린에서 list를 만들면 자바의 arrayList로 만들어냄. 그럼 이걸 래핑하는 객체로 무겁게 만드는게 아니라 진짜 해석해서 다 자바코드와 메소드로 바꿈 . 컴파일러가 무거운 추상층을 이용해서 플랫폼간 호환을 시키는게 아니라 플랫폼별 컴파일러가 굉장히 최적화를 많이함. 내이티브 코드에 근접하게.
3. 코틀린 collection framework의 가장큰 차이점은 추상화된 객체의 세트이긴 하지만 그건 우리한태 주는 프로그래밍 인터페이스인거고 컴파일러는 클래스 라이브러리를 알고 있기 때문에 컴파일 시에 네이티브코드로 바꿀때 이 추상화 프레임 워크를 그대로 가져가는게 아니라, 해체해서 네이티브 코드로 바꾸는 것임.
4. 그래서 기존에는 불가능했던 오버헤드와 사용성 간에 교환이 없어졌음. 둘다 좋게만듬.

fp와 oop

• 리액티브 프로그래밍이 나오는 이유는 코리커젼에 대해 반응하는 어떤 리스너를 만들고 싶은 것임.
• corecursion이 현재 모든 emit을 끝내지 않기 때문이다. corecursion이 값을 하나씩 만들어내는 과정을 emitting이라고 함.
• emiter가 언제 끝날지 모르기 때문에 emitting 할때마다 반응을 하는수 밖에 없다. 근데 반응하는 emitter가 함수형 fp라고 불리냐면 반응하는 emitter가 함수로 줬기 때문에가 아니라 실제로 진짜 함수형이 되기 위해선 내가 코리커젼으로 받는 값이 함수가 되야한다. 내가 코리커전으로 받고있는 값이 계속 emitting해서 옵저버가 받고 있는 값이 함수인 것임. 그럼 저쪽에선 함수만 가득히 만든거지 실제 실행은 내가 그걸 인수해서 쓸때 실행됨. 지연 실행이 거기까지 이어져야 fp임. 근데 우리가 쓰는 rx는 값이 넘어온다. 값을 이미 만들어 오는데 이쪽이 아니라 저쪽에서 이미 비용을 지불한것임. 원래는 지불하지 않고 함수로 감싸서 와야되는데 그래서 rx와 fp는 다른것임. fp는 함수로옴 . 끝까지 지연이 가능함. emitting을 하는데 emtting이 다 함수로 되어져 있기 때문에 실행하는 코드가 하나도 없기 때문에 부하가 하나도 없다. 옵저버가 받아들이고 실행할때 진정으로 실행이 되는것임. 그전까진 연산을 통한 누적으로 함수를 쌓아두기만 했는데 지금은 함수를 해소하는 함수 쪽으로 있어서 해소하는 쪽의 사정에 따라서 함수가 실행되기 시작한다. 그전엔 설계에 있는 연산에 따라서 순차적인 실행이 되는건데 지금은 그렇지 않고 수행하는 쪽에서 걔를 하나하나 깔지 말지를 결정이 가능함. 심지어 skip도.

리액티브 프로그래밍

• 리액티브 메니페스토 : 선언문
• 밑의 것들은 rx의 특징이 아니라 RX를 쓰는 이유가 이것들임. rx를 도입하고도 밑의 4가지를 달성하지 못하면 안쓰는게 낫다는 말임.
• 반응
• 복원
• 탄력
• 메시지 중심
• rx쓰는데 파편화 안되고 일관적이려면 rx를 쓰는 stream 처리기가 그 어플리케이션의 전부이면 된다. 그래서 서버를 마이크로 서비스로 만드는 것임. 마이크로 서비스 안에 observer stream을 observer stream 하나로 이 마이크로서비스를 구성할 수 있는 단위로 쪼개면 된다. 그럼 마이크로서비스 하나가 observable stream이다.
• 그리고 우리는 emiter에 반응하는게 쉽지 않음. 반응형 프로그래밍은 반응형박에 못씀. 가끔씩 취합해야할 경우엔 예를 들어 addEvent가 발생할때 마다 나한태 stream이 온다고 생각해 보자. 3번 오면 이벤트가 3개 들어왔으니 3개의 아이템이 쌓인걸 알아야 하는데 어케알지 ? 반응형인지 난 어케 상태를 갖지 상태가 없는데 어케알까? addItem이 올때마다 수신해서 어떻게 아이템 총개수를 갱신하는지? emitter가 2번 아이템과 2번 아이템까지 포함하는 총합도 같이 보냈기 때문에 알 수 있는 것임.따라서 observable의 반응형이 되는게 클라이언트라면 observerable로 짤때 많은 부하가 다 observerable 쪽으로 간다는 말임. obserbable이 emitting할때 자기가 갖고 있는 것임. sum 값도 같이 보내주는것임. 그래서 rx의 observerble을 쓸때 반응형 코드 쪽에 상태가 없으려면 상태를 포함한게 전부다 나한태 날라와야된다. emitting으로 그럼 상태는 다 observable쪽이 갖고 있어야한다. 사실 클라이언트는 서버와의 관계를 보면 일종의 옵저버다. 서버가 주는걸 받아드리는. 우리는 이 관계에서 똑같이 반응형에 대한 개념을 쓸 수 있음. 아이템을 나한태 던져주면 클라가 받아서 sum을 때릴거냐 아니면 서버가 아이템도 던지고 sum까지 던질거냐. 만약에 서버가 sum을 던지면 우리는 표시만 하면 되니까 반응형 클라이언트의 부담은 준다. 하지만 서버가 sum 값을 던지지 않으면 우리가(클라가?) 아이템을 던져야함. 아이템 더하는게 쉽지 않음. 이게 솔드아웃 됬는지 이런걸 다 확인 해봐야 되기 때문임.
• 그래서 observable이 쓰기 어려운 이유는 emitter 즉 코리커전에 익숙하지 않기 때문이다. 코리커전이 emitting하는 정보를 어떻게 만드는지 익숙하지 않아서 서버가 리액티브해야하는데 클라가 상태를 갖고 접근하는것임. 그래서 이게 망가지는 것임. 서버에서 아이템만 주고 sum은 내가 더해야 되는거다 그러면 클라는 상태를 가질 수 밖에 없음. 얘는 반응형이여야 하는데 상태 의존적이기 때문임. 그럼 순수 함수가 아니지 순수함수가 되려면 상태가 없어야함. 에미터쪽이 상태를 가져야 한다는 말이지 . 그래서 옵저버블쪽이 다 상태를 가져야함. 그래야 rx의 클라이언트가 되는 함수쪽이 순수함수가 되는것임. 근데 이게 어렵단 말이지.
• fp는 실현하기 굉장히 어렵고, observable도 rx를 써보면 그 효과가 잘 안나는 이유가 클라이언트 쪽에서 상태를 갖기 때문이다. 그래서 디버깅도 어려움.
• 일반적으로 최종 클라이언트만 순수함. 채인에 있는 모든애가 순수하진 않음. 아까 sum 을 던지는 애도 상태를 가짐. 순수하지 않다는 것임. 이렇게 마지막에 순수성을 확보하기 위해 중간에 상태를 갖는 subject를 엄청 끼워넣게됨. 그래서 subject가 observable인 동시에 observer이다. 이 특수 관계 때문에 나온것. 최종 옵저버를 보호하기 위해서.
• 코틀린의 확장함수는 rx의 기본적인 메소드를 기본적으로 제공한다.(297페이지)

펑터, 어플리커티브 ,모나드

1. 펑터

   • 코틀린의 펑터는 펑터가 아님 왜냐면 시퀀스로 바꾸지 않았기 때문이다.p.306
   • 리스트를 sequenceOf로 바꾸고 이걸 하면 펑터가될 가능성이 있음.
   • string이란 클래스가 생성자의 인자로 integer를 받는다면 toString을 내부에서 실행함.
   • 어짜피 string객체에는 getvalue란 메소드가 있어서 생성자로 다른 타입을 받아들일 수 있는데 toString이나 valueOf를 실행 시키면 string값이 나온다고 생각해보자.
   • 객체지향에선 굉장히 쉬움. 왜냐면 생성자로 받아들이는 애들을 field로 잡을 생각을 하고 있음. 그래서 메소드 호출하면 field를 이용할 생각을 하고 있기 때문이다. 즉 객체를 상태를 받는 상자라고 생각하고있기 때문에 그 상자안에 있는 값을 기억하고 있음으로써 메소드가 상태를 이용해서 얼마든지 만들어낼 수 있다는 사고방식을 갖는다. 이 모든게 상태를 가짐으로써 가능하게 되는것.
   • 그럼 함수는 대체 String이란 클래스를 어떻게 찾을까 ? 함수이다 그러면 String이라는 함수는 대체 무슨 함수일까 ? 내가 String이란 함수에게 A값을 넘겼는데 A가 integer나 boolean일 경우 String 함수는 나에게 뭘 반환해야할까 ? 함수를 반환해야함. 인자로 보냈던 값을 문자열로 바꿔서 출력해주는 함수를 반환하는 함수가 된다. 얜 객체가 아니라 함수를 사용함. 함수란 실행하기 전까지 연산을 지연시키는 놈임.따라서 함수형에서는 언제나 값을 평가하지 않고 지연할 수 있는 함수를 감싼게 그 type이되기도 하고 값이 되기도 함. 그러면 이 String 함수는 특정값 v를 받아들여 return으로 v.toString을 하는 함수를 반환하는 함수이다. 그럼으로써 객체와 굉장히 비슷한 일을 할 수 있음. 그함수를 호출해서 return값으로 함수를 들고 있다가 원할때 호출하면 문자열 값이 나오게 되는것임. 함수에서 모든 형은 맵함수가 반환되는 것임. map = type이 되는것임. 내가 아무값이나 보내면 string으로 바꿔주는(map)을 하는 함수를 나에게 반환하는게 형(type)임. 왜 map이 펑터가 되느냐 함수형의 기본형이 되느냐는 함수형에서 형이란건 String함수가 반환하는 함수 걔가 바로 타입(형)인데 걔는 한마디로 map임. 그래서 맵이 펑터이다. 그래서 내가 실행하기 전까지 실행 안된다. 그래서 IntegerArray에 맵을 걸어서 진짜 함수형에서 받으면 맵안에는 다 함수가 들어가 있음. 내가 map.{::toString}이란걸 걸어서 새로운 배열을 받아보면 그안에 나중에 호출해보면 string을 반환할 수 있는 함수가 들어가있을 것임. 하나하나의 형도 당연히 map이지만 컬렉션에 대한 맵도 그 컬렉션 전체를 string 타입으로 바꾼것임.
   • 펑터는 맵이다. 어떤걸 받아들여서 그 함수가 뭔갈 반환하는 함수니까 리턴값은 하나잔아 그럼 무슨 지랄을 했던간에 맵이다. 원래 본래의 값이 있는게 다른게 나왔잔아 걍 맵이야

2. 모나드

   • 플랫맵은 배열안에 배열을 하나의 배열로 플랫화 시켜주는건데 그럼 배열로 보면 배열안에 배열을 다시 배열로 바꾸는건?
   • 모나드란 맵이 펑터라고 불렀는데, 펑터를 받는 펑터도 있겠지? 일관적인 값을 받아들이는 펑터도 있겠지만 펑터를 갖는 펑터도 있음. 근데 어떤 펑터는 펑터 string도 가질 수도 있고 펑터 integer도 받아들일 수 있는 a라는 펑터가 있다고 생각해보면 a는 내부에 string 또는 integer라는 타입을 가질 수 있고 나는 펑터를 반환할건데 이 펑터는 최초에 발현하기를 integer 펑터나 sting 펑터를 가질 수 있는 펑터임. 그럼 애를 까보면 integer펑터나 string펑터가 나옴 하지만 이걸 감싸고 있는것임. 둘중에 하나일지 모르는 애를 하나로 감싸고 있는것임. 안에 까보면 둘중 하나 나오겠지만 두개를 합쳐서 하나가 감싸고 있는것임. 감싸고 있는 펑터는 둘중 하나를 가질 수 있음. 이걸 ADT라고 하는데, 얘의 실체를 알기 위해선 실행해서 진짜 펑터를 알아야함. 근데 그 펑터를 얻어버리면 걔는 더이상 감싸고 있는 펑터와는 호환이 되지 않음. 그래서 얘한태 값을 얻는건 이펑터를 호출해서 안에 있는 펑터를 꺼낸다음에 이 펑터로 호출하는 값을 얻었지만 이건 끝나지 않고 값인건 둘째 치고 펑터가 풀려서 나오면 이 펑터가 더 이상 감싼 펑터랑 호환되지 않음 . 얘를 잠깐 풀어서 값을 얻은다음에 얘를 다시 감싸서 그 형같이 아까 감싼 펑터로 바꿔야지만 원래의 펑터 형과 호환이 되는것임. 이걸 모나드라고 부른다.다른 펑터를 내부에 감추고 있는 펑터를 모나드라고 한다.
   • 모나드를 특정타입의 펑터를 받아들이는 펑터라고 생각하면 되고 그 펑터안에는 A타입 또는 B타입의 펑터가 들어올 수 있는 펑터라고 생각해 봐라. 그럼 이 펑터안에는 반드시 A타입 또는 B타입 중 한만 들어가 있음. 우리는 이 펑터 안에서 A타입 또는 B타입 펑터를 추출한다음에 이 값을 얻어야 함. 이렇게 추출해 버리면 얘는 더이상 (A타입과 B타입을)감싸고 있는 펑터가 아님. 그냥 A타입 또는 B타입의 펑터일 뿐이다. 이러면 원래 감싸진 펑터형에 묻는다. 꺼내서 값을 넣은 다음 다시 감싸서 그 펑터를 다시 만들어 줘야한다. 그래야 다음번에 펑터연산을 다시할 수 있음. 펑터연산은 펑터에서 꺼내서 연산하는거임. 다시 집어넣을려면 다시 감싸놔야함. 그래서 모나드에 대표적인게 optional이다. 이때 모나드가 펑터라고 생각하면 이펑터는 뭘 받을 수 있따 ? null 펑터 또는 값 펑터를 받을 수 있음. 그래서 플랫맵이 왜 필요하냐면 모나드를 풀어서 값을 얻기 위해 필요한 것이다.
   • 원래 큰 배열안에 있는 값들은 펑터인거고 배열안에 있는 것들이 다 펑터인건데 배열을 풀어야 펑터를 얻을 수 있음.([a,b,[c,d]])
   • 그래서 플랫맵은 모나드로부터 값을 얻을때 쓰는거다. 플랫맵을 쓰면 모나드로부터 값을 바로 얻을 수 있음.

3. 어플리커티브

   • 펑터를 이용하는 함수는 전체 다 어플리커티브이다. 내가 어떤 값을 직접 받지 않고 값 대신 펑터를 받아서 뭔갈 하는 함수들은 다 어플리커티브이다. 근데 왜 귀찬게 맵형 펑터를 만들어? 함수엔 형이 그것밖에 없다. 왜 펑터를 만드는지 이해를 못하는 이유는 상태가 존재한다고 생각하기 때문이다. 함수는 지연 연산의 연속이다. 함수형으로 프로그래밍을 짜면 메인함수가 호출되는 순간 내가 걸어놨던 모든 함수가 다 실행 되고있는것임. 하나도 상태가 미리 만들어지는게 없다. 다 미래에 이렇게 할거야라는 약속들을 계속 만들어갈 뿐이다. 타입 조차도 함수라서 미래에 너가 호출하면 내가 값을 줄게라는 것임.그러면 이 펑터를 어플리커티브에 주면 펑터를 받아들여서 어플리커티브를 실행하는 순간 풀어서 값을 얻어 연산을 한다. 내가 +2 라는 어플리커티브를 만들면 모나드로 인자로 뭘 받냐면 펑터 integer를 받을 것임 그럼 그 함수를 실행하는 순간 +2라는 함수를 실행하는 순간 펑터 인티저로부터 getValue를 그때 때리고 +2를 한걸 나한태 리턴하게 될것임. 그럼 무슨 이득을 얻냐면 펑터()해서 값을 얻는 행위를 어플리커티브를 실행할때까지 지연이 가능하다. 어플리커티브는 펑터의 메소드이다.